A large number of Distributed Denial of Service (DDoS) attacks, commonly referred to as flood attacks, appear on the network, where an attacked host or server has a large number of waiting Transmission Control Protocol (TCP) connections, and the network is filled with a large number of useless data packets. The attacker manufactures high-flow useless data and takes advantage of defects of service or transmission protocols provided by the victim host to repeatedly send a particular service request at a high speed, so that the victim host cannot promptly process all normal requests, thereby causing network congestion, and even worse, causing system breakdown. A Synchronize Sequence Number Flood (SYN Flood) is one of the major attack methods of the DDoS. The SYN Flood uses the intrinsic vulnerability of the TCP/Internet Protocol (IP), and connection-oriented TCP three-way handshakes are the basis for the existence of the SYN Flood. If a user gets into a sudden breakdown or off-line after sending a SYN message to the server, the server, after sending a Synchronize Sequence Number acknowledge (SYN_ACK) data packet, cannot receive an ACK data packet from a client (the third handshake cannot be completed). Under the circumstances, the server usually retries (resends the SYN_ACK data packet to the client) and waits for a period of time before discarding the uncompleted connection, where this period of time is referred to as a SYN timeout, and is generally in the level of minutes (about thirty seconds to two minutes). It is not a big problem that abnormality of one user causes one thread of the server to wait for one minute. However, if a malicious attacker simulates the situation on a large scale, it consumes the server a large amount of resources to maintain a large list of semi-connections. It consumes a large amount of Central Processing Unit (CPU) time and memory even if a simple storage and traverse is done, let alone continuous SYN_ACK retry on the IP addresses in the list. Actually, if the TCP/IP stack of the server is not strong enough, the final result is always a stack overflow or crash. Even if the system of the server is strong enough, the server is busy with the processing of fake TCP connection requests made by the attacker and has no time to pay attention to normal requests made by the client (after all, the ratio of the normal requests from the client is very low). At this time, as seen from the point of view of the normal client, the server becomes unresponsive. The situation is referred to as that the server is under a SYN Flood attack.
In a known authentication method for preventing a DDoS attack is provided, a gateway is employed to protect authentication. After receiving a SYN data packet, the gateway equipment sends a SYN_ACK data packet to the client, where a sequence number (SEQ) in the SYN_ACK data packet is constructed by the gateway according to information such as an IP address of the client. After receiving the SYN_ACK data packet, the client responds with an ACK data packet, where an acknowledgment SEQ of the ACK data packet is the SEQ of the SYN_ACK data packet plus one. When receiving the ACK data packet, the gateway records the source IP address of the client in a white list, and sends a RESET (RST) data packet to the client. The connection is released after the client receives the RST data packet. When the client resends the SYN data packet to request a connection within a certain time, the client can directly access the protected server within the aging time of the white list. Although Prior Art 1 can protect the server to some extent, the protective equipment has to send the return packet twice, which is a waste of resources.
In a known method for reducing flood attacks through a firewall, after receiving a SYN data packet, which is sent by a client and includes an SEQ, the firewall sends a SYN_ACK data packet to the client, where the SYN_ACK data packet includes an SEQ value and an ACK SEQUENCE (ACK) value, and the ACK of the SYN_ACK data packet is not equal to the SEQ of the SYN data packet plus one. After receiving the SYN_ACK data packet including the wrong ACK, the client sends an RST data packet to the firewall according to the requirements of the TCP/IP protocol. Under normal circumstances, the SEQ of the RST data packet is consistent with the ACK of the SYN_ACK data packet. The firewall checks whether the SEQ of the RST data packet matches the ACK of the SYN_ACK data packet, and if the SEQ of the RST data packet matches the ACK of the SYN_ACK data packet, designates the connection with the server as an authorized connection. In the method, the firewall is required to send the packet to the client only once so as to realize the authentication.
During the implementation of the present invention, the inventor finds that the above-described prior art example has at least the following defects.
The firewall carries out the authentication by checking whether the SEQ of the RST data packet matches the ACK of the SYN_ACK data packet, so that the firewall is required to store the ACK value of the SYN_ACK data packet after sending the SYN_ACK data packet. Once the network becomes abnormal or is under a flood attack, a large number of semi-connections exist in the network, and therefore, the firewall is required to store and maintain a large number of ACK values, thereby occupying storage resources.